Document made available under the 
Patent Cooperation Treaty (PCT) 



International application number: PCT/EP04/0 13797 
International filing date: 03 December 2004 (03.12.2004) 

Document type: Certified copy of priority document 

Document details: Country/Office: DE 

Number: 103 57 257.0 

Filing date: 08 December 2003 (08.12.2003) 



Date of receipt at the International Bureau: 03 February 2005 (03.02.2005) 



Remark: Priority document submitted or transmitted to the International Bureau in 
compliance with Rule 17.1(a) or (b) 




World Intellectual Property Organization (WIPO) - Geneva, Switzerland 
Organisation Mondiale de la Propriete Intellectuelle (OMPI) - Geneve, Suisse 



BUNDESREPUBLIK DEUTSCHLAND 




PCr/EP200. 4 / 0^|3?8F 



(D 



Prioritatsbescheinigung fiber die Einreichung 

einer Patentanmeldung / 

Aktenzeichen: 103 57 257.0 

08. Dezember 2003 

Giesecke & Devrient GmbH, 81677 Munchen/DE 

Bezeichnung: Java Smart Card Chip mit fur globale Variablen re- 

serviertem Speicherbereich 

IPC: G 06 K 19/07 



Anmeldetag: 
Anmelder/lnhaber: 



Die angehefteten Stucke sind eine richtige und genaue Wiedergabe der ur- 
sprunglichen Unterlagen dieser Patentanmeldung. 



Munchen, den 30. Dezember 2004 
Deutsches Patent- und Markenamt 
Der Prasident 
Im Auftrag 



Tava Smart Card Chip m it fur globale Variablen reserviertem Speicherbereich 

Die Erfindung betrifft einen Smart Card Chip mit einer virtuellen Java-Card- 
Maschine und einem fur globale Variablen reservierten Speicherbereich. 
5 Weiter betrifft die Erfindung ein Modul und eine Smart Card mit einem der- 
artigen Chip sowie ein Verfahren zum Implementieren eines Java Pro- 
grammcodes, insbesondere Java Pakets, in einen solchen Smart Card Chip. 

Smart Cards, d.h. Chipkarten mit Mikroprozessor, werden bereits heute und 
10 kxinftig voraussichtlich noch verstarkt bei einer Vielzahl von Anwendungen 
eingesetzt, beispielsweise bei Mobilgeraten wie z.B. Mobiltelefonen als SIM- 
Karten bzw. USIM-Karten, als Bankkarten oder elektronische Geldborsen im 
elektronischen Zahlungsverkehr, als Gesundheitskarten fur Versicherte von 
Krankenversicherungen (Patientenkarte) und Arzte (Arztekarte), als Biirger- 
15 karten, oder als Multiapplikationskarten, in denen mehrere der genannten 
oder anderer Funktionalitaten implementiert sind. 

Ein Smart Card Chip hat eine Mehrzahl von Speicherbereichen, namlich den 
nichtfliichtigen, nur einmal beschreibbaren ROM, den nichtfliichtigen, wie- 
20 derbeschreibbaren EEPROM und den fluchtigen, wiederbeschreibbaren 
RAM. Alternativ konnen Teile des ROM und/oder des EEPROM durch 
Flash-Speicher ersetzt sein. 

Bei der Herstellung des Smart Card Chips wird zunachst durch den Chip- 
25 hersteller ein ROM-Maske genannter Programmcode-Anteil, der vor allem 
das Betriebssystem enthalt, in den ROM implementiert. Anschliefiend wird, 
in der Regel durch den Smart Card Hersteller, der den Chip mit der imple- 
mentierten ROM-Maske vom Chiphersteller bezieht, die Komplettierung der 
Smart Card durchgefiihrt, bei der Erganzungen zum Betriebssystem und 
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Anwendungen des Smart Card Herstellers in den EEPROM implementiert 
werden. Nach erfolgter Komplettierung ist der Smart Card Chip fertig zur 
Herausgabe an den Kunden. 

5 Um plattf ormunabhangige und gut gegeneinander abgesicherte Anwendun- 
gen zu erstellen, eignen sich objektorientierte Programmiersprachen, insbe- 
sondere Java™ der Firma Sun Microsystems Inc., sehr gut. Die Laufzeitum- 
gebungen objektorientierter Programmiersprachen wie Java™ sind jedoch in 
der Regel zu umf angreich, um sie ohne Weiteres in einen Smart Card Chip 
10 implementieren zu konnen. 

Die Java Card™ Technologie der Firma Sun Microsystems Inc., die z.B. in der 
aktuellen - und laufend aktualisierten - Version in dem Dokument "Java 
Card™ 2.2 Runtime Environment (JCRE) Specification" (derzeit verfugbar 
15 unter http://java.sun.com/products/javacard) dargelegt ist, stellt eine abge- 
wandelte Java Technologie fur Laufzeitumgebungen mit beschrankten Sys- 
temressourcen dar, die sich auch fur Smart Cards eignet. 

Die in der Java Card (genauer im Chip) vorgesehene Laufzeitumgebung ge- 
20 mafi der JCRE Spezifikation umfasst zumindest die virtuelle Java-Card- 

Maschine (Java Card Virtual Machine) (JCVM) und die Java Card Applicati- 
on Programming Interface (API) Klassen, und ggf . noch weitere Komponen- 
ten. Im Zusammenhang mit der Erfindung wird unter der Virtuellen Ma- 
schine der Java Card oder virtuellen Java-Card-Maschine (im engeren Sinn) 
25 der On-Card-Anteil der virtuellen Java-Card-Maschine (im weiteren Sinn) 
verstanden. Der Begriff der virtuellen Maschine (VM) wird also im engeren 
Sinn aufgef asst und gleichgesetzt mit dem auf der Java Card vorgesehenen 
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On-Card-Anteil der VM. Neben dem On-Card-Anteil kann zusatzlich ein 
Off -Card- Anteil der VM im weiteren Sinn vorgesehen sein. 

Ein erstellter Programm-Quellcode (Source Code) eines vorbestimmten Pro- 
5 gramms, z.B. eines auf eine Java Card™ zu ladenden Programms, wird bei 
der Java™ Card Technologie zunachst, wie bei der Java™ Technologie, mit- 
tels eines Compilers kompiliert, so dass eine Klassendatei erzeugt wird, die 
das Format eines Zwischencodes, namlich des Java Bytecode, hat, der durch 
die virtuelle Java-Maschine interpretierbar ist. Anschliefiend wird bei der 

10 Java™ Card Technologie, im Unterschied zur Java™ Technologie, der Byte- 
code der Klassendatei zusatzlich mittels eines Konverters in einen konver- 
tierten Bytecode in einer cap-Datei (cap = Card Application Protocol) konver- 
tiert. Die Compilierung und Konvertierung wird aufierhalb der Java Card, 
„Off-Card", durchgefuhrt. Die cap-Datei, und somit letzten Endes das vorbe- 

15 stimmte Programm, wird auf die Java Card geladen, und der Bytecode der 
cap-Datei wird gelinkt. Beim Linken werden u.a. Zugriffsmoglichkeiten des 
mit der cap-Datei auf die Java Card geladenen Programms auf andere in der 
Java Card vorhandene Programmcode-Elemente eingerichtetd.h. es werden 
Verbindungen zwischen den einzelnen Packages hergestellt. Beim Linken ist 

20 zu unterscheiden zwischen dem Offcard-Linker und dem Oncard-Linker. 

Der Oncard-Linker ist in der Java Card (im Chip) implementiert und ist ohne 
weitere Komponenten funktionsf ahig. Der Offcard-Linker benotigt zum Lin- 
ken eine Export-Datei, die Informationen fur das Linken enthalt, und die 
nicht mit in die Java Card (den Chip) geladen wird. Die virtuelle Java-Card- 

25 Maschine interpretiert schliefilich den konvertierten und gelinkten Bytecode 
der cap-Dateien und fiihrt ihn aus. 
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In der Regel ist Java-Programmcode in Form von Paketen (packages) abge- 
legt. Jedes Paket enthalt einen Teil des Programmcodes, z.B. Daten oder ein 
oder mehrere einzelne Programme. Die einzelnen Programme konnen ent J 
weder Systemfunktionen des Betriebssystems (in kompilierter Form: Sys- 
5 temklassen) oder Anwendungen sein. Die Strukturierung des Programmco- 
des in Pakete ist auch in der konvertierten cap-Datei beibehalten. 

In der cap-Datei enthalt jedes Paket neben dem eigentlichen Programmcode 
zusatzlich eine Import-Komponente und eine Export-Komponente. 

10 

In der Import-Komponente ist festgelegt, welche Zugriffsmoglichkeiten das 
Paket auf andere Pakete benotigt, z.B. welche Methoden aus anderen Pake- 
ten das Paket benutzen mochte. Die benotigten Zugriffsmoglichkeiten wer- 
den beispielsweise durch eine Ref erenz „import<anderes Paket>" in der Im- 
15 port-Komponente angegeben. Dabei wird eine solche ,,import<...>"-Ref erenz, 
die der Form nach eine Namensref erenz (Ref erenz, die auf einen Namen ge- 
richtet ist, z.B. auf „anderes Paket") ist, bei der Erzeugung der cap-Datei 
i.d.R. in ein sogenanntes Token umgewandelt, das der Form nach eine 
Nummernref erenz (Ref erenz, die auf eine Nummer gerichtet ist) ist. 

20 

In der Export-Komponente ist festgelegt, welche Zugriffsmoglichkeiten das 
Paket anderen Paketen bietet, d.h. z.B. welche Methoden das Paket anderen 
Paketen zur Benutzung zur Verftigung stellt. Die zur Verfiigung gestellten 
Zugriffsmoglichkeiten werden beispielsweise durch die Angabe einer Adres- 
25 se in der Export-Komponente erzielt, wobei durch die Adresse der Speiche- 
rort des zur Verfiigung gestellten Programmcodes angegeben ist. 
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Dass ein neu in eine Java Card geladenes Paket tatsachlich auf ein vorbe- 
stimmtes anderes Paket zugreifen und dessert Programmcode nutzen kann, 
wird durch das Linken eingerichtet. Dabei, beim Linken, ladt das neu gela- 
dene Paket Linkinformation (z.B. eine Adresse) aus der Export-Komponente 
5 des anderen Pakets in die eigene Import-Komponente. Beispielsweise wird 
beim Linken ein Token, d.h. eine aus einer ,,import"-Referenz erzeugte 
Nummernref erenz, in der Import-Komponente des neuen Pakets durch eine 
Adresse aus der Export-Komponente des anderen Pakets ersetzt. Hierdurch 
wird der Token (die Referenz) mit dem Benutzungswunsch durch eine tat- 
10 sachliche Adress-Verkniipfung zwischen den beiden Paketen ersetzt. Die 
Verkntipfung und damit die tatsachliche Benutzungsmoglichkeit kann nur 
eingerichtet werden, wenn dem neu geladenen Paket die Export-Kompo- 
nente des anderen Pakets, dessen Programmcode das neue Paket nutzen 
will, zur Verfiigung steht. 

15 

Die Export-Komponenten aller Pakete, die in einer Java Card implementiert 
sind, oder eine vorbestimmte Teilmenge aller dieser Export-Komponenten, 
sind in der Export-Datei zusammengefasst. Wird vor der Komplettierung 
der Java Card ein zusatzliches (neues) Paket in die Java Card nachgeladen, 
20 wird es unter Verwendung des Off card-Linkers und der Export-Datei ge- 

linkt. Nach der Komplettierung der Java Card kann zum Linken nur der On- 
card-Linker verwendet werden. 

Anwendungen sind in der Regel in Form von Applets in der Java Card imp- 
25 lementiert, wobei die Applets wiederum zu Anwendungs-Paketen gruppiert 
sind. Bei den Anwendungs-Paketen gibt es sogenannte preloaded packages 
(preissuance packages), die vor oder bei der Komplettierung in den Smart 
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Card Chip implementiert werden, und die in der Regel durch den Smart 
Card Hersteller implementiert werden. Weiter gibt es postloaded packages 
(postissuance packages), die nach erfolgter Komplettierung in den Smart ' 
Card Chip geladen werden, in der Regel durch den Abnehmer oder Kunden, 
5 beispielsweise ein Kreditinstitut oder eine Behorde. 

Die Inhalte (z.B. Applets bzw. Systemfunktionen) unterschiedlicher Pakete 
sind durch Firewalls gegeneinander abgesichert, wohingegen die Inhalte 
(Applets etc.) innerhalb ein und desselben Pakets nicht mittels Firewalls ge- 
10 geneinander abgesichert sind. 

Java stellt eine Reihen von unterschiedlichen Variablentypen zur Verfiigung. 
Z.B. gibt es eine Reihe von nicht globalen, auf ihren Kontext beschrankten 
und dynamisch erzeugten Variablen, z.B. Instanzvariablen oder gleichbedeu- 

15 tend Objektvariablen (instance variables), lokale Variablen (local variables) 
und Methodenparameter (method parameters). Instanzvariablen, lokale Va- 
riablen, Methodenparameter haben gemeinsam, dass sie dynamisch wah- 
rend der Lattfzeit eines Programms mit dem Objekt (== Instanz einer Klasse), 
dem Ablauf (z.B. Programmschleife), der Methode etc. erzeugt werden, zu 

20 dem sie gehoren und nur so lange existieren wie das Objekt, der Ablauf bzw. 
die Methode existiert, d.h. sie sind transient. Zudem sind sie nicht global, 
d.h. sie sind nur innerhalb des Kontexts (d.h. innerhalb des Objekt, des Ab- 
laufs bzw. der Methode) verwendbar, in bzw. mit dem sie erzeugt worden 
sind. Uber den Kontext hinaus verhindert die Firewall, dass die Variablen 

25 verwendet werden, d.h. der Zugriff auf die Variablen von aufierhalb des 
Kontext ist durch die Firewall verhindert. 
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Der fiir Instanzvariablen reservierte Speicherbereich liegt auf dem heap- 
Speicher, im nichtfliichtigen EEPROM (oder alternativ im Flash-Speicher). 
Der fiir lokale Variablen reservierte Speicherbereich liegt auf dem Stack- * 
Speicher, im RAM, und hat nur eine kurze Lebensdauer, namlich die Dauer 
5 der Methoden-Ausftihrung. 

Der Nachteil der nicht globalen Variablen ist, dass sie aufierhalb ihres Kon- 
text nicht verwendbar sind. 

10 Neben den bereits genannten Variablen gibt es als die einzigen globalen 

(s.u.) Variablen bei Java die Klassen variablen, die statisch erzeugte Variablen 
sind (class variables, static variables). 

Klassenvariablen (gleichbedeutend verwendeter Begriff: static Variablen) 
15 sind globale Variablen, d.h. sie sind nicht an einzelne Instanzen einer Klasse 
(= einzelne Objekte) gebunden. Klassenvariablen werden statisch deklariert, 
wobei der fiir die Klassenvariablen reservierte Speicherbereich im EEPROM 
liegt, also in einem nichtfliichtigen Speicherbereich der Java Card. 

20 Schreibzugriffe auf den EEPROM sind langsam und kosten daher viel Zeit. 
Aus diesem Grund ist der Zugriff auf Klassenvariablen langsam, weshalb die 
Performance eines Programms, das Klassenvariablen verwendet, gering ist. 
Zum Anderen erlaubt ein EEPROM lediglich eine Hochstzahl von typi- 
scherweise 100 000 Schreibzyklen, weshalb es wiinschenswert ist, Schreib- 

25 zugriffe auf den EEPROM wo moglich zu vermeiden. Die Verwendung von 
Klassenvariablen, insbesondere in Fallen, wenn nur eine kurze Lebensdauer 
der Variablen erforderlich ist, verlangsamt somit die Performance des Pro- 
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grammablaufs und belastet durch die dabei erfolgenden Schreibprozesse den 
EEPROM. 

Andererseits besteht der Bedarf, Variablen global, also unabhangig vom 
5 Kontext eines speziellen Objekts, Pakets, einer speziellen Methode etc. zu 

verwenden, beispielsweise £iir den Austausch von Variablen zwischen unter- 
schiedlichen Kontexten (Objekten, Paketen, Methoden) etc.. Derzeit ist diese 
Moglichkeit nur durch Klassenvariablen gegeben, die die weiter oben ge- 
nannten Nachteile haben, wie starke Belastung des EEPROM und Langsam- 
10 keit. 

Aufgabe der Erfindung ist es daher, einen Smart Card Chip mit einer virtu- 
ellen Java-Card-Maschine und einem fiir globale Variablen reservierten Spei- 
cherbereich zur Verfiigung zu stellen, der einen einf achen, schnellen und fiir 
15 den Chip schonenden Zugriff auf die globalen Variablen ermoglicht. 

Die Aufgabe wird gelost durch ein Variablen-System nach Anspruch 1. Vor- 
teilhafte Ausgestaltungen der Erfindung sind in den abhangigen Anspru- 
chen angefiihrt. 

20 

Der Smart Card Chip gemafi Anspruch 1 hat einen fiir globale Variablen re- 
servierten Variablen-Speicherbereich, der im fluchtigen Arbeitsspeicher re- 
serviert ist, beispielsweise im RAM. Zugriffe auf den fluchtigen Arbeitsspei- 
cher sind schnell und zudem wird dadurch, dass der fliichtige Arbeitsspei- 
25 cher verwendet wird, der nichtfliichtige Anwendungsspeicher, insbesondere 
EEPROM oder ein Flash-Speicher, geschont. Hierdurch ermoglicht der Chip 
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gemafi Anspruch 1 einf achen, schnellen und fiir den Chip schonenden 
Zugriff auf die globalen Variablen. 

Daher ist gemafi Anspruch 1 ein Smart Card Chip mit einer virtuellen Java- 
5 Card-Maschine und einem fur globale Variablen reservierten Speicherbereich 
geschaffen, der einen einf achen, schnellen und fur den Chip schonenden 
Zugriff auf die globalen Variablen ermoglicht. 

Die Erfindung ist insbesondere fur Anwendungsfalle fiir globale Variablen 
10 gut geeignet, bei denen die Variablen zwar global sein mxissen, z.B. weil sie 
iiber Kontextgrenzen hinaus verfugbar sein miissen, bei denen aber eine lan- 
ge Lebensdauer der Variablen nicht erforderlich ist. Derm der (schnelle) 
RAM-Speicher, in dem der Speicherbereich fiir die Variablen reserviert ist, 
und in dem die Variablen bei Bedarf angelegt werden, ist fliichtig. Folglich 
15 werden die angelegten Variablen geloscht, sobald die Energieversorgung des 
RAM-Speichers unterbrochen wird. 

Vorzugsweise ist der Variablen-Speicherbereich statisch reserviert, bei- 
spielsweise dadurch, dass der Variablen-Speicherbereich fiir Klassenvariab- 

20 len reserviert ist (gleichbedeutend: Variablen vom Typ static), da der 

Zugriff auf die Variablen bei einer statischen Reservierung besonders schnell 
ist. Ein Zugriff (Lesezugriff bzw. Schreibzugriff) auf den statisch reservierten 
Variablen-Speicherbereich bedeutet, dass eine statisch reservierte Variable 
(Variable vom Typ static) verwendet (gelesen oder iiberschrieben) wird. Da 

25 bei der Verwendung von statisch reservierten Variablen keine Firewall- 
Priifung durchgefuhrt wird, hat die statische Reservierung des Variablen- 
Speicherbereichs den zusatzlichen Vorteil, dass der Zugriff auf die Variablen 
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schneller ist als wenn der Variablen-Speicherbereich dynamisch, wahrend 
der Laufzeit des Programms reserviert wiirde. Folglich ist es besonders be- 
vorzugt, dass der Variablen-Speicherbereich statisch reserviert ist. 

5 Weiter ist es bevorzugt, dass solche Programme auf den Variablen-Speicher- 
bereich zugreifen konnen, die auf den Variablen-Speicherbereich linken kon- 
nen. Dabei ist weiter vorzugsweise das Vermogen eines Programms, auf den 
Variablen-Speicherbereich linken zu konnen, dadurch erzielt, dass dem Pro- 
gramm zum Linken eine Export-Komponente auf dem Smart Card Chip zur 

10 Verfugung steht. Der Variablen-Speicherbereich erscheint fur ein Programm, 
das darauf zugreifen will, wie ein fremdes Programm. Daher benotigt das 
Programm, das auf den Variablen-Speicherbereich zugreifen will, die Export- 
Information des fremden Programms, das den Variablen-Speicherbereich 
geschaffen hat. Vorzugsweise hat also ein Programm, das den reservierten 

15 Variablen-Speicherbereich nutzen mochte, zum Linken die Export- 
Komponente eines fremden Programms zur Verfugung, das den Variablen- 
Speicherbereich geschaffen hat. 

Weiter sind vorzugsweise solche Programme davon ausgeschlossen sind, 
20 den Variablen-Speicherbereich zu nutzen, die nicht auf den Variablen- 
Speicherbereich linken konnen. Das Unvermogen eines Programms, auf den 
Variablen-Speicherbereich linken zu konnen, ist vorzugsweise dadurch er- 
zielt, dass dem Programm zum Linken eine Export-Komponente des Smart 
Card Chips vorenthalten ist. 

25 

Weiter bevorzugt ist der Variablen-Speicherbereich dadurch reserviert, dass 
in einem Systemspeicher des Chips ein entsprechendes Java Paket abgelegt 
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ist, das vorzugsweise nur die Reservierung des Variablen-Speicherbereichs 
enthalt. Eirt solches Java Paket mit dem Namen z.B. 

,,com.gieseckedevrient.javacard.os.commonram", 
das Speicherplatz fur eine Mehrzahl von statischen Variablen „myRamVa- 
5 rA", // myRamVarB // , etc. vom Datentyp short und Byte und Int reserviert, 
kann beispielsweise folgende Gestalt haben: 

package com.gieseckedevrient.javacard.osxommonram; 
static short myRamVar A; 
10 static short myRamVarB; 

etc. 

Das Java Paket wird im Systemspeicher (ROM, ggf . auch Flash-Speicher) ab- 
gespeichert. Bei der spateren Verwendung des Java Pakets werden die ent- 
15 sprechenden Daten, d.h. die statischen, globalen Variablen vom Typ short, 
Byte, Int im RAM abgelegt. 

Weiter ist es bevorzugt, dass auf den Variablen-Speicherbereich nur im Sys- 
temspeicher (ROM, Flash) abgespeicherte Programme zugreifen konnen. 
20 Alternativ oder zusatzlich konnen vorzugsweise auf den Variablen- 
Speicherbereich nur Programme zugreifen, die bis zum Abschluss der Kom- 
plettierung des Smart Card Chips in dem Smart Card Chip implementiert 
worden sind. 

25 Gemafi einer bevorzugten Ausfuhrungsform wird nur fur Pakete, die bis zur 
Komplettierung implementiert werden, zum Linken die Export-Komponente 
zur Verfiigung gestellt. Ein geladenes Paket, das bis zur Komplettierung 



-12- 



implementiert wird, wird vorzugsweise mit dem Off card-Linker und der 
Export-Datei gelinkt. Dadurch wird die Linkinformation zum Linken auf den 
Variablen-Speicherbereich aus der Export-Komponente des Java Pakets, das 
den Variablen-Speicherbereich reserviert, in die Import-Komponente des 
5 geladenen Pakets geladen. Die Folge ist, dass das geladene Paket auf den 
reservierten Variablen-Speicherbereich zugreif en kann und dort, im RAM, 
die RAM-Variablen benutzen kann. Pakete, die nach der Komplettierung in 
die Java Card bzw. den Chip implementiert werden, haben in ihren Import- 
Komponenten nicht die Linkinformation aus der Export-Komponente des 
10 Java Pakets, das den Variablen-Speicherbereich reserviert hat. Daher konnen 
gemafi der bevorzugten Ausfiihrungsform nach der Komplettierung imple- 
mentierte Pakete die erfindungsgemafien RAM-Variablen nicht benutzen, 
d.h. nicht auf den reservierten Variablen-Speicherbereich im RAM zugreifen. 

15 Die virtuelle Java-Card-Maschine ist vorzugsweise derart gestaltet, und da- 
bei bei Bedarf gegeniiber der virtuellen Java-Card-Maschine gemafi der Java 
Card VM Spezifikation modifiziert, dass sie auf Grundlage des im fliichtigen 
Arbeitsspeicher (RAM) reservierten Variablen-Speicherbereichs die Verwen- 
dung von globalen Variablen im RAM ermoglicht. 

20 

Insbesondere sind bei Bedarf die Befehle „getstatic" und „putstatic" der 
virtuellen Java-Card-Maschine gegeniiber den Befehlen „getstatic" und 
„putstatic // virtuellen Java-Card-Maschine gemafi der Java Card VM Spezi- 
fikation modifiziert. 

25 

Vorzugsweise sind die bei Bedarf vorgenommenen Modifizierungen oder 
Anderungen an der virtuellen Java-Card-Maschine derart vorgenommen, 
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dass die Modifizierungen / Anderungen bei der Verwendung der VM nach 
aufien nicht qualitativ erkennbar sind. Dass die Modifizierungen qualitativ 
nicht erkennbar sind, bedeutet insbesondere, dass der Smart Card Chip einer 
vorbestimmten Java Card Spezifikation geniigt, der der Chip ohne die Modi- 
5 fikationen ebenfalls geniigen wiirde. Quantitativ konnen die Modifizierun- 
gen optional nach aufien erkennbar sein, z.B. kann nach aufien erkennbar 
sein, dass das Verwenden der erfindungsgemafien globalen RAM-Variablen 
schneller ist als das Verwenden von bekannten globalen Variablen aus dem 
Stand der Technik. Insbesondere sind die bei Bedarf an den Befehlen 

10 „getstatic" und „putstatic" vorgenommenen Anderungen vorzugsweise 
derart durchgefuhrt, dass das Verwenden (z.B. Anlegen, Variablenwert an- 
dern) von static Variablen unter Verwendung der Befehle „getstatic" und 
„putstatic" unverandert ist gegeniiber dem Verwenden (z.B. Anlegen, Va- 
riablenwert andern) von static Variablen gemafi der Java Card VM Spezifi- 

15 kation. 

Dass die Anderungen nach aufien nicht qualitativ erkennbar sind, wird bei- 
spielsweise dadurch erreicht, dass ein Variablen-Speicherbereich fur globale 
Variablen im RAM reserviert wird, wobei fur die Reservierung eine ansons- 
20 ten der Java Card VM Spezifikation gentigende Variablen-Deklaration ver- 
wendet wird, beispielsweise eine Deklaration von static Variablen, nur mit 
dem Unterschied, dass die static area im RAM statt im EEPROM vorgesehen 
ist. 

25 Die Einhaltung der Spezifikationen wird vorzugsweise ferner dahingehend 
gewahrleistet, dass ein normaler Benutzer den reservierten Variablen- 
Speicherbereich nicht benutzen kann, d.h. keine erfindungsgemafien RAM- 
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Variablen benutzen kann, da ihm die Linkinformation fehlt, weil ihm die 
zum Linken erforderliche Export-Datei vorenthalten ist. Beispielsweise wird 
die Export-Datei beim Hersteller der Smart Card verwahrt und gegeniiber ' 
Benutzern wie Abnehmern von Smart Cards geheim gehalten. Vorzugsweise 
5 konnen nur Programmentwickler von Systemprogrammen (und wahlweise 
zusatzlich von preloaded packages), die vor der Komplettierung gelinkt 
werden, die erfindungsgemafien RAM-Variablen verwenden, da nur diesen 
Programmentwicklern von Systemprogrammen (und ggf. preloaded packa- 
ges) die geheime Export-Datei und somit die zum Linken auf den reservier- 

10 ten Variablen-Speicherbereich erforderliche Linkinformation zur Verfugung 
steht. Nur Programmentwickler von Systemprogrammen (und ggf. preloa- 
ded packages) sind also von der allgemeinen Geheimhaltung der Export- 
Datei ausgenommen. Abnehmer von Smart Cards, die nach der Komplettie- 
rung der Smart Card Programme (z.B. Anwendungen) in die Smart Card 

15 (bzw. in den Smart Card Chip) laden, konnen zum Linken hingegen nur den 
Oncard-Linker verwenden, der die Linkinformation zum Linken auf den 
reservierten Variablen-Speicherbereich im RAM nicht hat. 

Im f olgenden wird die Erfindung anhand von Ausfuhrungsbeispielen und 
20 unter Bezugnahme auf die einzige Figur 1 der Zeichnung naher erlautert. 

Fig. 1 zeigt eine schematische Darstellung einer Java Card mit einem darin 
implementierten RAM package 5 , durch das ein Variablen- 
Speicherbereich 18 im RAM der Java Card statisch reserviert ist, ge- 
25 mafi einer bevorzugten Ausfuhrungsf orm der Erfindung. 
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Die Java Card aus Fig. 1 hat einen nichtfliichtigen Systemspeicher 1, namlich 
den ROM 1, einen nichtfliichtigen Anwendungsspeicher 2, namlich den 
EEPROM 2, und einen fluchtigen Arbeitsspeicher 3, namlich den RAM 3. ■ 

5 Im ROM 1 sind die virtuelle Java-Card-Maschine VM 4 und weiterer nativer 
Code implementiert. Zudem sind im ROM 1 eine Reihe von Paketen Pckgl, 
Pckg2, ... Pckgn mit unterschiedlichen Inhalten, zum Teil Systemfunktionen 
und zum Teil Anwendungen, implementiert. Aufierdem ist im ROM 1 das 
erfindungsgemafie RAM package 5 implementiert, also das Java Paket, 

10 durch welches der Variablen-Speicherbereich 18 im RAM reserviert ist. Im 
EEPROM 2 sind mehrere vor der Komplettierung in die Java Card geladene 
Pakete mit Anwendungen, namlich mehrere preloaded EEPROM packages 
16, abgespeichert. Zudem enthalt der EEPROM 2 einen heap-Speicher 19 mit 
dynamischen Daten (Dynamic Data), mehrere Puff erspeicher (Buffers) und 

15 einen Bereich mit nativen Daten. Der RAM 3 enthalt native RAM-Daten, den 
durch das RAM package reservierten Variablen-Speicherbereich 18 (RamP.- 
Data), zwei Pufferspeicher (Buffer), einen Arbeitsspeicherbereich, der auf 
Anfrage geloscht wird (COD, Clear On Demand) und einen Arbeitsspeicher- 
bereich, der bei Reset, also bei Riicksetzen, geloscht wird (COR, Clear On 

20 Reset). 

Die virtuelle Maschine VM 4 in Fig. 1 enthalt beispielsweise die Befehle der 
VM 4 wie z.B. „putstatic" 7, mit dem sich eine static Variable zur Laufzeit 
andern lasst, wie durch den vergrofierten Ausschnitt 7 der VM mit der Be- 
25 schriftung „Putstatic" angedeutet ist. 
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Im beschriebenen Beispiel von Fig. 1 gibt es weiter eine in der Java Card 
implementierte Zugriffstabelle (SAT, segment allocation table), die u.a. die 
Anfangsadressen der in der Java Card implementierten Pakete (packages) ' 
enthalt. 

5 

Die Zugriffstabelle SAT enthalt insbesondere fiir das RAM package einen 
static area descriptor 8, d.h. einen in dem RAM package 5 enthaltenen De- 
skriptor 8 (oder eine Angabe), der einen Anfang und eine Grofie eines be- 
stimmten Adressbereichs als Speicherbereich fiir statisch deklarierte (reser- 

10 vierte) Variablen angibt. Der Deskriptor 8 (static area descriptor) enthalt 

zwei Teilangaben, namlich die Anfangsadresse des Adressbereichs und die 
Grofie des Adressbereichs. Die Anfangsadresse ist so gewahlt, dass der 
'durch den static area descriptor 8 bestimmte Adressbereich im RAM 3 der 
Java Card liegt, wie durch die Pfeile 12, 13 angedeutet ist, die vom Deskrip- 

15 tor 8 (static area descriptor) zum RAM 3 verlaufen. Durch die derart getrof- 
fene Auswahl der Anfangsadresse (d.h. Auswahl der Anfangsadresse so, 
dass der reservierte Variablen-Speicherbereich im RAM liegt) ist eine direkt 
auf den RAM-Speicher gerichtete Zugriff sinf ormation gebildet. Dass der De- 
skriptor 8 (static area descriptor) auf eine Adressangabe im RAM verweist, 

20 stellt eine Anderung gegenxiber der Java Card VM Spezifikation dar, die je- 
doch nach aufien nicht erkennbar ist. 

Das in Fig. 1 dargestellte Paket 6 mit der Nummer „n", bezeichnet mit 
„Pckgn // , ist ein preloaded package, d.h. ein Paket, das vor der Komplettie- 
25 rung der Java Card in der Java Card implementiert worden ist, und enthalt 
im ROM-Speicher 1 der Java Card abgelegten Paket-Code 9, wie durch den 
vergrofierten Ausschnitt 9 „Preloaded Pack. Code" angedeutet ist. Der Pa- 
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ket-Code 9 des preloaded package 6 wiederum enthalt Code fur einen Kon- 
stantenpool 10 („Const. Poor) und Code 11 fiir den Befehl „putstatic" der 
VM. Durch „putstatic // 11 im Code des preloaded package 6 (Pckgn) wird 
unter Verwendung des Konstantenpools 10 eine Variable vom Typ static 
5 adressiert, und zwar im RAM 3, im reservierten Variablen-Speicherbereich 
18, wie durch die Pfeile 14, 15 angedeutet ist, die von „Code putstatic" zu 
„Const. Pool ..." (Pfeil 14) und von „ Const. Pool ..." zu „RamP. Data" (Pfeil 
15) verlaufen. Das preloaded package Paket Pckgn 6 wurde durch den Off- 
card-Linker und unter Verwendung der Export-Datei der Java Card gelinkt. 

10 Dabei wurde das preloaded package Paket Pckgn 6 mit Linkinformation des 
RAM package 5 ausgestattet, insbesondere mit der Adresse, die im Deskrip- 
tor 8 fiir static Variablen (static area descriptor) steht. Hierdurch hat das 
preloaded package Pckgn 6 die Linkinformation des RAM package 5. Folg- 
lich kann das preloaded package Pckgn 6 den reservierten Variablen- 

15 Speicherbereich 18 des RAM package 5 benutzen, also erfindungsgemafie 
globalen Variablen (RAM static Variablen) benutzen. 

Bei dem Beispiel aus Fig. 1 kann ein postloaded package 16, das im EEPROM 
implementiert ist, nicht auf den im RAM 3 reservierten Variablen- 
20 Speicherbereich 18 zugreifen, so dass das postloaded package 16 im 

EEPROM keine erfindungsgemafien globalen Variablen im RAM benutzen 
kann. Nur Pakete im Systemspeicher ROM konnen die globalen Variablen im 
RAM benutzen. 

25 Gemafi alternativen Ausfuhrungsformen konnen auch preloaded packages 
im EEPROM die globalen Variablen im RAM benutzen. Die preloaded pa- 
ckages im ROM haben dann, wie die packages im Systemspeicher ROM 
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auch, die vom Off card-Linker in der Export-Datei bereitgestellte Adressin- 
f ormation, mit der sie auf den reservierten Variablen-Speicherbereich linken 
konnen, so dass sie den reservierten Variablen-Speicherbereich im RAM fur 
Variablen benutzen konnen. 



Patentanspriiche 



1. Smart Card Chip mit einem rrichtfluchtigen Systemspeicher (ROM, 
Flashl), einer in dem nichtfliichtigen Systemspeicher (ROM, Flashl) imple- 

5 mentierten virtuellen Java-Card-Maschine, einem nichtfliichtigen Anwen- 1 
dungsspeicher (EEPROM, Flash2), einem fliichtigen Arbeitsspeicher (RAM) 
und einem fur globale Variablen reservierten Variablen-Speicherbereich, 
wobei der Variablen-Speicherbereich im fliichtigen Arbeitsspeicher (RAM) 
reserviert ist. 

10 

2. Smart Card Chip nach Anspruch 1, wobei auf den Variablen- 
Speicherbereich nur im Systemspeicher (ROM, Flash) abgespeicherte Pro- 
gramme zugreifen konnen. 

15 3. Smart Card Chip nach Anspruch 1 oder 2, wobei auf den Variablen- 
Speicherbereich nur Programme zugreifen konnen, die bis zum Abschluss 
der Komplettierung des Smart Card Chips in dem Smart Card Chip imple- 
mentiert worden sind. 

20 4. Smart Card Chip nach einem der Anspriiche 1 bis 3, wobei der Vari- 
ablen-Speicherbereich statisch reserviert ist. 

5. Smart Card Chip nach einem der Anspriiche 1 bis 4, wobei der Vari- 
ablen-Speicherbereich durch eine direkt auf den Arbeitsspeicher (RAM) ge- 

25 richtete Zugriffsinformation reserviert ist. 

6. Smart Card nach einem der Anspriiche 1 bis 5, wobei solche Pro- 
gramme auf den Variablen-Speicherbereich zugreifen konnen, die auf den 
Variablen-Speicherbereich linken konnen. 



-2- 



7. Smart Card Chip nach Anspruch 6, wobei das Vermogen eines Pro- 
gramms, auf den Variablen-Speicherbereich linken zu konnen, dadurch er- 
zielt ist, dass dem Programm zum Linken eine Export-Komponente auf dem 

5 Smart Card Chip zur Verftigung steht. 

8. Smart Card Chip nach einem der Anspriiche 1 bis 7, wobei solche 
Programme davon ausgeschlossen sind, den Variablen-Speicherbereich zu 
nutzen, die nicht auf den Variablen-Speicherbereich linken konnen. 

10 

9. Smart Card Chip nach Anspruch 8, wobei das Unvermogen eines Pro- 
gramms, auf den Variablen-Speicherbereich linken zu konnen, dadurch er- 
zielt ist, dass dem Programm zum Linken eine Export-Komponente des 
Smart Card Chips vorenthalten ist. 

15 

10. Smart Card Chip nach einem der Anspriiche 1 bis 9, wobei der Vari- 
ablen-Speicherbereich durch ein in dem Smart Card Chip implementiertes 
Java Paket (RAM package) reserviert ist. 

20 11. Smart Card Chip nach Anspruch 10, wobei das Java Paket (RAM pa- 
ckage) im Systemspeicher (ROM, Flashl) implementiert ist. 

12. Smart Card Chip nach Anspruch 10 oder 11, wobei das Java Paket 
ausschliefilich die Reservierung des Variablen-Speicherbereichs enthalt. 

25 

13. Smart Card Chip nach einem der Anspriiche 10 bis 12, wobei eine Ex- 
port-Komponente des Java Pakets (RAM package), in der die zum Linken 
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auf den reservierten Variablen-Speicherbereich erforderliche Linkinformati- 
on enthalten ist, nicht in dem Smart Card Chip implementiert ist. 

14. Smart Card Chip nach einem der Anspriiche 1 bis 13, wobei die virtu- 
5 elle Java-Card-Maschine derart gestaltet ist, und dabei bei Bedarf modifiziert 
ist, dass sie auf Grundlage des im fliichtigen Arbeitsspeicher (RAM) reser- 
vierten Variablen-Speicherbereichs die Verwendung von globalen Variablen 
im RAM ermoglicht. 

10 15. Smart Card Chip nach Anspruch 14, wobei die virtuelle Java-Card- 
Maschine derart modifiziert ist, dass die Modifizierungen nach aufien hin 
nicht qualitativ erkennbar sind, insbesondere dass der Smart Card Chip einer 
vorbestimmten Java Card Spezifikation geniigt, welcher der Chip ohne die 
Modifikationen ebenf alls geniigen wiirde. 

15 

16. Chipmodul mit einem Smart Card Chip gemafi einem der Anspriiche 
1 bis 15. 

17. Datentrager, insbesondere Java Card, mit einem Smart Card Chip ge- 
20 mafi einem der Anspriiche 1 bis 15 und/oder einem Chipmodul gemafi An- 
spruch 16. 

18. Verfahren zum Reservieren eines Variablen-Speicherbereichs in einem 
Smart Card Chip, der aufweist: eine nichtfliichtigen Systemspeicher (ROM, 

25 Flashl), eine in dem nichtfliichtigen Systemspeicher (ROM, Flashl) imple- 

mentierte virtuelle Java-Card-Maschine, einen nichtfliichtigen Anwendungs- 
speicher (EEPROM, Flash2) und einen fliichtigen Arbeitsspeicher (RAM), 
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wobei bei dem Verfahren ein Java Programmcode in dem Smart Card Chip 
implementiert wird, durch den ein Variablen-Speicherbereich fiir globale 
Variablen im fliichtigen Arbeitsspeicher (RAM) reserviert wird. 

5 19. Verfahren nach Anspruch 18, wobei als Java Programmcode eine Java 
Paket (RAM package) implementiert wird. 

20. Verfahren nach Anspruch 19, wobei eine Export-Komponente des Ja- 
va Pakets, in der die zum Linken auf den Variablen-Speicherbereich erfor- 

10 derliche Linkinformation enthalten ist, nicht in dem Smart Card Chip imp- 
lementiert wird. 

21. Verfahren nach einem der Anspruche 18 bis 20, wobei eine zum Lin- 
ken auf den reservierten Variablen-Speicherbereich erforderliche Export- 

15 Datei nur solchen Programmen zum Linken zur Verfiigung gestellt wird, die 
auf den Variablen-Speicherbereich zugreifen konnen sollen. 



Zusammenfassung 



Die Erfindung schafft einen Smart Card Chip mit einem rrichtfliichtigen Sys- 
temspeicher (ROM, Flashl), einer in dem nichtfliichtigen Systemspeicher 
5 (ROM, Flashl) implemeritierten virtuellen Java-Card-Maschine, einem nicht- 
fliichtigen Anwendungsspeicher (EEPROM, Flash2), einem fliichtigen Ar- 
beitsspeicher (RAM) und einem fur globale Variablen reservierten Variablen- 
Speicherbereich, wobei der Variablen-Speicherbereich im fliichtigen Arbeits- 
speicher (RAM) reserviert ist. Der Variablen-Speicherbereich ist vorzugswei- 
10 se statisch reserviert. Die Verwendung der Variablen kann auf Systempacka- 
ges und wahlweise zudem auf preloaded (ROM/ EEPROM) packages be- 
schrankt sein. 

Figur 1 

15 



